Subject: Propagation of RIF Broadcast Indicators in CANUREACH

From: "Steve Klein" <[email-masked]>
Date: Thu, 26 May 94 10:17:28 EDT

Refrence: Note from Gnanaprakasam Pandian dated Thu, 19 May 94 10:36:32 PDT

>> - propagation of Routing Control Field Largest Frame Bits in SSP messages
>> - including in the CANUREACH message the frame (TEST, XID) that generated
>>   it
>
>        Could you add RIF type bits to that.
>                00 - specific route
>                01 - All rings, all routes
>                11 - All rings, spanning routes

Gnanaprakasam, why would it be necessary to propagate the RIF broadcast
bits to a DLSw partner?  Shouldn't the broadcast type be managed locally?
What if the origin station is on an ethernet or SDLC line?

Steve

---

From: Gnanaprakasam Pandian <[email-masked]>
Date: Thu, 26 May 94 9:44:55 PDT

Hi Steve,

> >                10 - All rings, all routes <== correction 
						  thanks to Choon Lee
> Gnanaprakasam, why would it be necessary to propagate the RIF broadcast

call me pandian please.

> bits to a DLSw partner?  

To preserve the end-to-end semantics of the stations.
Ideally one would like DLSw to preserve whatever the end-stations
exchange among them.

Assume a CUR frame hits a target switch and it has three TR interfaces
and its spanning tree algorithm puts one of the three in a blocked
mode. 

If the origin station sends a single route broadcast
the target switch which recieves a CUR should not broadcast it to
the blocked TR interface.

If the CUR has the RIF type information carried along
the target switch could do the right thing.

Also, one could possibly run spanning tree algorithm between switches
replacing he whole DLSw box with two bridges and an intermediate ring.

Thinking about configurations where two DLS switches are connected by a
local bridge getting the same copy of an explorer through an SSP CUR
message and release it on their respective token rings,
I am not sure about the ramifications of such interactions.
For sure there will be multiple copies appearing on the same ring.

> Shouldn't the broadcast type be managed locally?

sometimes not possible.

Also, we did not carry the C/R bit in the SSP
messages and invented an XID FSM to recreate the bit
on each side. We could not do the same here,
besides being computationally expensive 
for the following reson.

The XID fsm is made possible because the XID behavior is fairly consistent,
like if I have received a command before this must go as a response.

Some NETBIOS frames go all routes out and some others go single route
out depending on the implementation.
To make a judgement call about
	 all routes out/single route back 
		versus 
	 single route out/all routes back 
the frame type(NBNQ/NBNR..) is just not enough.
(Could someone verify this?)

The final goal is to avoid multiple copies appearing on a ring
when we know we could prevent it.

What do you think?

> What if the origin station is on an ethernet or SDLC line?

It would not apply as much as the LF (Max MTU) field.
Could I assume that when the SDLC is mapped to a TR paradigm for DLSw
we could use this LF field to carry the SDLC line max MTU.

-- 
G. Pandian           + Gnanaprakasam Pandian      +
Cisco Systems, Inc.  + Software Engineer          +           
1525 O'Brien Drive   + Phone : (415)688-7684      +
Menlo Park,          + FAX   : (415)688-8282      +
CA 94026             + E-mail: [email-masked] +

---

From: Choon Lee <[email-masked]>
Date: Thu, 26 May 1994 11:33:54 -0700

>> replacing he whole DLSw box with two bridges and an intermediate ring.

Running the bridge spanning tree algorithm between DLSw switches is not
going to work because bridges has 2 major differences from DLSw:
(1) bridged frames gets "switched" from one bridge port to another 
    (e.g. a bridge frame goes from A to B to C), while DLSw does not.
(2) DLSw as defined today "tunneled" only a subset of bridgable frames 
    (LLC2 and Netbios).

On the other hand, if we consider a similar sort of spanning tree that only
DLSw participates in, and a full mesh topology in the switch "cloud",
then that may be done.

There has been much discussion of parallel paths between LAN segments in
the Loop prevention RIGlet, and we are hoping that a solution can be
obtained.

Choon Lee

---

From: "Alan K. Bartky, Manager of Technology" <[email-masked]>
Date: Thu, 26 May 94 12:37: 9 PDT

Fellow RIGlet members -

Here are some comments on the current discussion on Broadcast Indicators.
My comments have been marked with "AKB>"

Regards,

Alan

P.S. These comments are from Alan the engineer, not Alan the editor.

--- Begin (edited) Included Message ---

AKB> This is not necessarily true for all connections.  We have found that for 
AKB> our SDLC to LLC converters, sometimes single-route works better, sometimes
AKB> all-routes works better.  It really depends on the topology and the equipment
AKB> used in the interconnected token-ring network.  Considering that two DLSw boxes
AKB> might communciate with different token-ring Internetworks across an IP network,
AKB> it might make sense to not use the same method with the two Token-Ring network
AKB> and that propagation of the bits would not make much sense.  My understanding of
AKB> the philosophy of DLSw was to establish and maintain the Data - Links at each side
AKB> independent of the other.
AKB> 
AKB>

AKB> The origin station is communicating with the DLSw router, not with the
AKB> other end-station.  The LLC2 connection is local, not end-to-end.  Again the protocol
AKB> and topology of the Token-Ring nets on both sides are a better determinant of
AKB> which broadcast method to use.

sometimes not possible.

AKB> According to the IBM Local Area Reference Technical reference, all Broadcast frames
AKB> use single-route broadcast except the NAME_RECOGNIZED frame which uses an all routes.
AKB> This means the Add name Query would/should use an Single-route broadcast with an
AKB> All routes return.  Again even in NETBIOS, any subsequest SABMEs to establish
AKB> an LLC connection would generate a local connection.  Significance of broadcast
AKB> methods for NETBIOS should only apply to UI frames, not CANUREACH messages.

What do you think?

> Steve

AKB> One last thought might be (as a compromise if it is needed) would be
AKB> to pass the information and that the DLSw switch could, based on implementation,
AKB> on received CANUREACH messages either:
AKB>   1) Use the same method as the one passed.
AKB>   2) Use the one it thinks it should be using
AKB>   3) Use the one that a user has configured as the method to use
AKB>   4) If the end station is SDLC or Ethernet it would ignore the field
AKB>  All NETBIOS UI frames should use the rules spelled out in the IBM reference manual

    
--- End (edited) Included Message ---